More laser tracks

____

Nov.8, 2007

According to StLaserEventMaker, the laser rafts are slightly rotated with respect to the coordinate system. It looks like the laser origins match something like the following:

  int i;

  float rr = 196.6;

  float off = 0.014;

  for (i=1;i<12;i+=2) printf("%f %f\n",rr*cos((3.14159*i/6.)+off),rr*sin((3.14159*i/6.)+off));

168.867804 100.673866

-2.752049 196.580743

-171.619857 95.907179

-168.868071 -100.673418

2.751528 -196.580751

171.619603 -95.907634

So I can use these positions as the point with which to investigate angles. Note that in the laser events, hits on tracks are already given a sector association. ftksector is decided by the transverse distance of closest approach to the above points, and separated in z by cuts at:

  static const Float_t zcut[13]={-165,-140,-105,-75,-45,-15,

                15,45,75,105,135,165,195};

  static const Float_t zpt[12] = {-179.2, -151.6, -120.5, -90.7, -59.6,

               -32.0, 32.0, 59.7, 90.7, 120.6, 151.7, 179.2 };

Note that the assumption that the lasers are at multiples of 30 is pretty reasonable, and the ~7cm offset of the laser T0 in the data which I'm studying is probably not enough to shift them out of a given z bin, though the z bins really don't have much impact on the sector to which the tracks get associated.

What can be a problem for the association to sectors is tracks on opposite sides of the IFC. I definitely see, for example, radial tracks associated with sector 2 which are clearly in sector 8 and cannot have gone through the IFC. This might mean that when trying to find good tracks, I should keep to hits near their origin.

________

Nov. 12, 2007

Phew! Major re-working of macros into: filterLasersC.C, findLasersR07.C

  root4star -b -q -l 'filterLaserR.C+("st_junk3_5022006_*.root")'

...

  root -l -q 'findLasersR07.C("../NoCorr/5022006R/","Nominal")'

B is 5063104

C is 5063106

But it looks like we're getting there. Now I've got to figure out how to deal with the following: the lasers are linear vs. x, y, or frr (distance from their origin), but not vs. r. In fact, they generally are two-valued in r (on both sides of their closest approach to the IFC). Note that I have my distortion maps as a function of r. What I really want is r vs. r! Well, r_measured vs. r_real.

We want to look at the distortion in r. So we want to plot r as a function of....frr? phi? x and y are poor choices because some tracks are nearly vertical or horizontal and the points will stack atop each other. Same can be true for r*phi. phi vs. frr is monotonic and not too far from linear. So either of those is probably reasonable. But then I'll need to calculate the expected r from the phi or frr? Hmmm...

_________

Nov. 13, 2007

I think what I want from plotsR07.C is to match appropriately hits from the two file sets. r vs. frr lets me do that pretty well. Then, once I've that information, I can plot delta(r) vs. r to see the distortion.

Drat: I got that working just to figure out that the hits will be reconstructed along the padrows, which won't be distorted. So the distortion will be along the padrow.Therefor, I will see but the azimuthal and radial distortion to these hits (displacement along the padrow will be due to both)! Argh! That makes it tough.

For each hit, I need: r, observed distortion, and direction of distortion? Formerly, we had only needed r, and distortion, since we knew the direction was in r-phi. Hm. Can we determine both r and direction of distortion from one quantity? I believe so...frr, or frr' (distance from the x and y offsets)....

x = xoffset + frr'*cos(psi)

y = yoffset + frr'*sin(psi)

r = sqrt(x^2+y^2)

phi = atan2(y,x);

sector' = floor(phi*6.0/pi+0.5); // 0 = sector 3, 1 = sector 2, etc...

phi_sector = sector'*pi/6.0;

phi_padrow = (sector' + 3.0)*pi/6.0;

I need to actually determine the distortion along the padrow in plotsR07.C if I want to save only these two pieces of information. So I should be plotting padrow position vs. frr' to have all the information I need....

phi_diff = phi - phi_sector;

y_sector = r*sin(phi_diff);

"sqrt(fx*fx+fy*fy)*sin(atan2(fy,fx)-(0.5236*floor(0.5+atan2(fy,fx)/0.5236))):frr'"

Then when I do the comparison to the map, I will need to project the map's distortion along the padrow. Map says delta_rphi(r,z) and delta_r(r,z), I'll obtain a magnitude and phi_delta angle from the two deltas, then project the magnitude to the padrow angle by using the mag*cos(phi_delta - phi_padrow).

It occurs to me in all of this that I'm generalizing this enough that I could be doing the radial tracks along with this. I don't see any reason why not. It actually boils down to doing about the same thing as the radial track analysis because frr is about the same vector as the radius, and the padrow direction becomes rphi. Great!

Wait....I've actually thrown away the radius of the hit....I need to put that back in. So I need to make the ntuples just a little bigger. Still need to cut tracks from opposite side of IFC. I've started re-running to get the radial ones too.

For testing:

  root -l -q 'plotsR07.C+("Nominal.dat",6,7,706,2.0,"./%03d/",50000)'

  root -l -q '../DrawDiff.C("../Hists_7.root","../../Nominal.dat")'

To get something sensible, it looks like I need to be pretty strict with the errors on the points:

  fits.Draw("d-r:x:z:z","de>0&&re>0&&de<0.2&&re<0.2")

Last step....fit.C. Needs to be update to handle two component omegataus....

  root -l 'fitR.C("../data/analysisR/Hists/Examine7/fits.root","../JIMCODE/dist_140.dat",0)'

______

Nov. 14, 2007

Re-ran filterLaserR.C now alowing the radial tracks. Re-ran findLasersR07.C and turned up lots of new tracks, but lost a few:

sector 4 , phi 1.884 , z = 59.87 : looks to be a good track. Should keep.

sector 8 , phi -0.201, z = 32.64 : looks to be a bad track. Should trash.

sector 12, many lasers ... looks like the job might have crashed at this point! I'll just re-run sector 12 for now, but this is a problem I should fix.

Amalgamating it all together into Nominal_good.dat obtains 145 laser tracks. Wow!